This is most of the code from the scene titled "Mineshaft" near the beginning of A Mess O'Trouble. Because it was one of the first scenes I did in that game, it's not a polished as some of my other scene codes, and has some unnecessary code. However, it's an easy scene to get to, so you can read the code, then follow the action in the game to see how it works. I'll go through each section of code and explain it.
To understand best how scene code and global code work, you need to know how the program goes through it. When the player first enters a scene, the program searches through the scene code to see if there is anything that must be done at the beginning of that scene. Then, if no scene code prevents it, it goes on to print the scene text (if any), and then checks the global code for any zero-loop instructions there.
The first section of code in the scene is this:
IF{LOOP#=0}THEN
LET{H1#=H1#-1}
LET{H2#=H2#-1}
LET{H3#=H3#-1}
END
This updates the variables for eating, drinking and sleeping each time the player enters the scene. It is a way of simulating the passage of time, and thus the player's need to eat, drink and sleep. LOOP#=0 means that it does this only when the player enters the scene, and is ignored during any actions (loops) that the player makes while in the scene.
It finishes with END, because this allows the program to go on after performing this action. If I'd used EXIT here, it would have stopped before it even printed the scene text.
IF{TEXT$=LOOK}AND{LOOP#>0}THEN
PRINT{......................................}
IF{TEXT$=UP}OR{TEXT$=SHAFT}THEN
PRINT{The sky is just a tiny square patch of blue at the top of the shaft. It's a long way up, at least 80 to 100 feet.}
EXIT
END
This next section of code allows the player to do the action "Look up", or "Look up the shaft". Notice that it isn't necessary to code in the word "the" in the sentence. Use only the important keywords the player will use in your code, and the program will ignore the unimportant parts of the player's sentence.
Here, LOOK is the first keyword. However, LOOK is also a command that prints the scene text. So the second IF/THEN statement distinguishes it from the standard LOOK command. In other words, if the player just says LOOK, it will print whatever the scene text description is, whether the scene description is in the scene text or in seperate code. But if the player says LOOK, and the words UP or SHAFT are in the sentence, then it prints the appropriate "looking up" text.
In my games, I like to precede every response with a dotted line, which seperates the text from any text already in the window, making it easier to read. So this section of code also includes that dotted line, plus I've added a second condition to the first line. The first condition is IF{TEXT$=LOOK}. The second condition is AND{LOOP#>0}. This means it won't do anything that follows unless the loop # is greater than 0. Why did I do that? So that the scene description won't have the dotted line in front of it when the player first enters the scene. But if the player asks for the scene description later in that scene, it will print the dots first, seperating it from the text already in the text window. It also prints the dots before it prints the response to LOOK UP.
The second IF/THEN statement, IF{TEXT$=UP}OR{TEXT$=SHAFT}, ends with the word EXIT. This makes sure the program stops after telling the player what he sees when he looks up. Otherwise it would continue until it got to the scene description, and print that too.
The section ends with the word END, which allows the program to continue to the scene description.
IF{LOOP#=0}OR{TEXT$=LOOK}THEN
PRINT{You are at the bottom of a deep shaft. A bit of dim light shines down from above. Inky black tunnels run to the NORTH and SOUTH. The stench of death and decay hangs in the air.}
PRINT{......................................}
PRINT{You are facing NORTH.}
END
This section of code handles the scene description. It prints it when the scene is first entered (LOOP#=0) and when the player requests the scene description (LOOK). Normally this can just be entered in the scene text window. The only reason to put it into code is if something changes the scene description. To be frank, I can't remember why I coded it in this scene, it doesn't look like it needs to be! In the nearby scenes, the scene text changes, depending on whether or not the player has the flashlight and fresh batteries.
IF{TEXT$=SEARCH}THEN
PRINT{~~~~~~~~~~~~}
PRINT{The mineshaft has no timbers, just bare stone. There doesn't seem to be any way to climb up.}
PRINT{The floor of the shaft is littered with rotting bits of timber.}
IF{START.ROPE=SCENE@}THEN
PRINT{.............................}
PRINT{There is a rope dangling down the shaft. The end of it is just out of reach.}
EXIT
EXIT
This is the SEARCH code. It contains a nested IF/THEN statement, that modifies the search text if the rope is in the scene. The line of squiggles at the beginning serves the same purpose as the dotted line. However, I wanted the search text to really stand out, so I used squiggles instead of the usual dots.
If there was no specific search text, except for the rope part, I would have ended it with END, and let the default response handle it.
PRINT{You can't do that while carrying that heavy rock.}
EXIT
IF{START.ROPE=SCENE@}THEN
IF{BEAM.1=SCENE@}THEN
MOVE{START.ROPE}TO{STORAGE@}
PRINT{Standing on the beam allows you to reach the rope. But as you start to climb, the rope suddenly gives, and you fall to the floor of the shaft.}
PRINT{The rope falls too. It must not have been securely tied.}
SOUND{OOOF}
MOVE{ROPE}TO{SCENE@}
EXIT
PRINT{You can't reach the rope.}
EXIT
PRINT{You can't climb up the shaft.}
EXIT
This section gets a bit more complicated. It handles the response for when the player enters CLIMB or UP, or when the player clicks on the rope object in the scene. (The rope object is not the actual rope, but an immobile object that is a drawing of the rope hanging down the shaft.)
It contains a few nested conditions. The first is an IF/THEN that checks to see if the player is carrying the rock. If so, it tells him that he can do those things while carrying the rock, and stops the program there. If the player does not have the rock, it continues to the next part of the code.
The next IF/THEN checks to see if the rope object is in the scene. If it is, then there is another IF/THEN that checks to see if the beam object is in the scene. (The beam must be in place in order for the player to reach the rope.) If the beam object is in place, then the program removes the rope object, moves the actual rope to the scene, and prints the text telling the player what happened. If the beam object is not in the scene, it prints a response telling the player that he can't reach the rope.
If the rope object is not in the scene, it prints a response that tells the player he can't climb up the shaft. The program stops at that point, as there are no further responses.
IF{TEXT$=JUMP}THEN
PRINT{...........................}
IF{ROCK=PLAYER@}THEN
PRINT{You can't do that while carrying that heavy rock.}
EXIT
IF{START.ROPE=SCENE@}THEN
PRINT{You jump as high as you can but still can't reach the rope.}
EXIT
PRINT{You can't jump high enough to get out, the top of the shaft is at least 80 to 100 feet up.}
EXIT
This is similar to the CLIMB code. It contains nested IF/THEN statements that check to see if the player is carrying the rock, and check to see if the rope object is in the scene. This is followed by a general response, and EXIT.
PRINT{You can't do that while carrying that heavy rock.}
EXIT
IF{ROPE=PLAYER@}THEN
PRINT{There is no way to secure the rope.}
EXIT
PRINT{You don't have a rope.}
EXIT
IF{TEXT$=ROCK}OR{TEXT$=STONE}THEN
PRINT{What do you want to do with the rock?}
EXIT
IF{TEXT$=BEAM}OR{TEXT$=TIMBER}OR{TEXT$=BOARD}THEN
IF{ROCK=PLAYER@}THEN
PRINT{You can't do that while carrying that heavy rock.}
EXIT
IF{BEAM=PLAYER@}THEN
MOVE{BEAM.1}TO{SCENE@}
MOVE{BEAM}TO{STORAGE@}
PRINT{The wooden beam is now propped against the wall of the shaft, just below the rope.}
PRINT{The short cross piece makes a good step.}
EXIT
IF{BEAM.1=SCENE@}THEN
PRINT{What do you want to do with the beam?}
EXIT
PRINT{The wooden timbers that litter the floor of the shaft are too rotten to do anything with. The other timbers are supporting the tunnel.}
EXIT
END
Now we get to the complicated stuff! This section of code is inteded to respond to the command verb USE, with nested IF/THEN statements that determine what it is the player wants to use, how the object is to be used, and whether or not current conditions permit it to be used. Because there are different ways a player might tell the program to use the beam (the key component of the puzzle), I've added as many of those verbs to the code as possible. Such as PLACE, PUT, SET, LEAN and PROP. This way, if the player enters, "Lean the beam against the shaft" or "Put the beam under the rope", the program won't just say "Huh?" I always try to include as many verb variations as I can, it makes the game less frustrating.
This section of code contains numerous nested conditions (IF/THEN statements). The first one checks to see if the player has used the word ROPE. If so, then it checks to see if the player has the rock. If the player has the rock, he is prevented from taking that action. The next condition checks to see if the player actually has the rope. If so, it tells him there is no way to secure the rope. Finally, if both conditions are negative (no rock, no rope), it prints a response stating that he has no rope. The program EXITs at that point, since that is the end of the code dealing with using the rope.
Next is a short IF/THEN that checks to see if the player has used the words ROCK or STONE. If so, it prints a response asking for specifics. In some cases, there would be additional nested conditions here, dealing with ways to use the rock. In this particular case, I was running out of room for scene code, so I coded only the most likely uses of the rock, which are dealt with elsewhere in the code. Such compromises are often necessary in World Builder, because of the code space limitation built into it.
The next condition checks to see if the player has used the words BEAM, TIMBER or BOARD. Once again, a check is made to see if the player has the rock, since carrying the heavy rock limits the player's ability to take any other actions. Then the program checks to see if the player has the beam. If so, it then moves the beam to storage, and moves the beam object to the scene and prints a response.
If the player doesn't have the beam, then it checks to see if the beam object is in the scene, and prints a response asking what the player wants to do with it. (The usual request is to stand on it, but anything else will get a default response.) If all conditions are negative (no rock, no beam, no beam object in the scene) then it assumes the player is referring to the other timbers in the mine, either the support timbers or the loose rotting wood on the floor, and prints an appropriate reply. The program then EXITs.
The entire section of code for the command verb USE ends with the word END. This allows the program to continue to the global default response for the verb USE ("That doesn't seem to work.") In this way, if the player tries to use an object other than the most likely ones, he will receive an intelligent reply.
World Builder has two built-in default responses to anything it doesn't understand: "Huh?" and "What?" Any more intelligent default response must be written into the code, either in the scene code or the global code. Such common commands as "USE ...." should have the response written into the global code, since it will be required from any scene in the game. Specific situations within a scene can have their own defaults.
IF{TEXT$=THROW}THEN
PRINT{...........................}
IF{TEXT$=ROPE}THEN
IF{ROPE=PLAYER@}THEN
PRINT{There is no way to secure the rope.}
EXIT
PRINT{You don't have a rope.}
EXIT
IF{TEXT$=ROCK}OR{TEXT$=STONE}THEN
PRINT{The rock is much too heavy to throw.}
EXIT
IF{TEXT$=BEAM}OR{TEXT$=BOARD}THEN
PRINT{The beam is too heavy to throw.}
EXIT
END
This section deals with the command verb THROW. The nested conditions should be self-explanatory by now. Due to space limitations, I didn't add any conditions to check to see if the player actually has the object named in the command. Since in each case the action is refused anyway, checking to see if the player had the object wasn't really necessary. In a case where the action CAN occur, and is crucial to the game, such conditions would be vital, otherwise the player could complete the puzzle even if he didn't actually have the needed object. The only place this kind of conditional statement was needed was with the rope, since there are two possible responses, depending on whether the player has the rope or not. Even here, if space was too tight, I might have deleted that condition and got away with it.
The statement ends with END, allowing the program to continue to the global or built-in default. World Builder understands THROW, since it is a common weapon verb, and has a built-in default for objects that can't be thrown. So in most cases it is not necessary to write a custom default in the global code.
IF{TEXT$=DIG}THEN
PRINT{...........................}
PRINT{The floor is stone. It's too hard to dig.}
EXIT
This is self-explanatory. Since the puzzle here is to escape the mine, and digging seems a likely means of escape, I wanted to offer an explanation why that action isn't possible, rather than using the global default, which merely says, "You can't dig here." Anytime the player is prevented from making a possible solution to the puzzle he should be given a plausible reason.
IF{TEXT$=BREAK}OR{TEXT$=HIT}THEN
IF{TEXT$=FLOOR}THEN
PRINT{...........................}
IF{ROCK=PLAYER@}THEN
PRINT{The rock is too big and heavy to use as a hammer. You can only drop it.}
EXIT
PRINT{You need a sledgehammer, or some other hard heavy object.}
EXIT
END
Again, this one is self-explanatory. And since there is no hammer or similar object available, there is no need to put in any code dealing with the actual use of such an object. The statement ends with END, and a default response to BREAK and HIT is written into the global code.
IF{TEXT$=STAND}OR{TEXT$=CLIMB}THEN
PRINT{................................}
IF{TEXT$=BEAM}OR{TEXT$=BOARD}OR{TEXT$=TIMBER}THEN
IF{ROCK=PLAYER@}THEN
PRINT{You can't do that while carrying that heavy rock.}
EXIT
IF{BEAM=SCENE@}THEN
PRINT{The beam is just laying on its side. If would make a better step ladder if you leaned it against the wall.}
EXIT
IF{BEAM.1=SCENE@}THEN
PRINT{You are now standing on top of the beam.}
IF{START.ROPE=SCENE@}THEN
PRINT{You can now reach the rope.}
EXIT
PRINT{You can't reach anything from here, so you hop back down.}
EXIT
PRINT{The timbers on the floor are too rotten, and there's no way to use the timbers that support the tunnel.}
EXIT
IF{TEXT$=ROCK}THEN
IF{ROCK=SCENE@}THEN
MOVE{STARS}TO{SCENE@}
SOUND{OOOF}
MOVE{STARS}TO{STORAGE@}
PRINT{You fell off the rock, you klutz!}
EXIT
IF{ROCK=PLAYER@}THEN
PRINT{You have to drop the rock first.}
EXIT
PRINT{There aren't any rocks here large enough for that.}
EXIT
END
This section handles the verbs STAND and CLIMB. However, CLIMB should have been left off, since it was handled earlier in the code. Like I said, this was not one of my most polished codes!
The program checks to see what the player wants to stand on, either the beam or the rock. It then checks to see if the named object is in the scene, or if the player is carrying it, and prints an appropriate response. If player asks to stand on the beam, and the beam object is in the scene, then it checks to see if the rope object is in the scene.
PRINT{You can't pick up anything while carrying that heavy rock.}
EXIT
IF{TEXT$=ROCK}OR{TEXT$=STONE}THEN
IF{ROCK=SCENE@}THEN
MOVE{ROCK}TO{PLAYER@}
PRINT{You now have the large rock. The rock is so heavy you can hardly lift it.}
EXIT
PRINT{There are no suitable rocks here.}
EXIT
IF{TEXT$=BEAM}OR{TEXT$=BOARD}OR{TEXT$=TIMBER}THEN
IF{BEAM=SCENE@}THEN
MOVE{BEAM}TO{PLAYER@}
PRINT{You now have the beam.}
EXIT
IF{BEAM.1=SCENE@}THEN
MOVE{BEAM.1}TO{STORAGE@}
MOVE{BEAM}TO{PLAYER@}
PRINT{You now have the small beam.}
EXIT
PRINT{None of the beams on the ground are any good, and if you move the support timbers the tunnel will collapse.}
EXIT
IF{TEXT$=ROPE}THEN
IF{BEAM ROPE.2=SCENE@}THEN
MOVE{BEAM ROPE.2}TO{STORAGE@}
MOVE{ROPE}TO{PLAYER@}
PRINT{You now have the rope.}
EXIT
IF{START.ROPE=SCENE@}THEN
IF{BEAM.1=SCENE@}THEN
MOVE{START.ROPE}TO{STORAGE@}
PRINT{Standing on the beam allows you to reach the rope. But as you start to climb, the rope suddenly gives, and you fall to the floor of the shaft.}
PRINT{The rope falls too. It must not have been securely tied.}
SOUND{OOOF}
MOVE{ROPE}TO{SCENE@}
EXIT
PRINT{You can't reach the rope.}
EXIT
END
END
This lengthy section handles the common verbs GET and TAKE, and also does double duty, handling less common verbs that still are likely to be used by some players. UNTIE is treated the same as GET or TAKE, since in this case the only way that verb would ever be used is if the player wants to untie the rope and take it. LIFT, MOVE, CARRY and STACK are also treated the same as TAKE, partly because those actions are close equivalents to TAKE in this particular scenario, and partly due to lack of space for a more detailed handling of those verbs.
After checking to see if the player has the rock, it then checks to see if the player is asking to pickup or move a rock. If so, it checks to see if the rock is in the scene, and moves it to him if it is. If the rock is not in the scene, it prints a reply stating that there are no suitable rocks. This is necessary since the graphic of the scene shows a few small stones among the rubble, just to provide realistic detail.
Next it checks to see if the player used the words BEAM, BOARD or TIMBER. (These words are used interchangably here, since one player might call it a beam, while another might call it a board, or the player may be referring to the support timbers. Never rely too much on the player using the correct word!) A couple of checks are then made to see if the beam itself is in the scene, or the beam object. This is done because the player may have simply dropped the beam here, or may have used it and now wants to take it again to use elsewhere. In each case, the program handles the situation appropriately.
If the player has not used any of the words already handled in this section, the program continues down the line, checking to see if the word ROPE was used next. If so, then several more checks must be made. Since the player has the option to tie the rope to a support beam, the program must check to see if the tied rope object is in the scene, and if so, must remove it and move the rope to the player. If not, then it checks to see if the hanging rope object is in the scene. If it is, the player can only reach it if the beam object is also in the scene, so a check is made to see if that is the case. If both these conditions are true (rope object in scene, beam object in scene) then it moves the rope object to storage, moves the rope to the scene, plays a sound, and prints the text. If the beam is not in the scene, then it prints a reply stating that the player can't reach the rope. If the rope object is not in the scene, then the code ENDs, allowing the program to run to the built-in defaults.
For picking up movable objects, there are several defaults built into WB. If the player clicks on the object, it is moved to the player. If the player says GET followed by the name of the object, then if the object is in the scene, it is moved to the player. If the player already has that object, then it replies, "You already have (name of object)." If the object is not in the scene and the player doesn't have it, then it replies with the standard "Huh?"
If the object is immobile, the default response is "You can't move that." Immobile objects are actually graphics, such as drawing of open and closed doors, used to make changes in the scene, and things that can be clicked on. If something in the scene can never be moved or changed, but the player must be able to click on it for a description or other information, you can just use an invisible immobile object positioned over that part of the scene drawing.
Immobile objects should not be given common names, to prevent confusion. The easiest way to name immobile objects is to combine the name with the scene it will be used in, or number it, or both. For instance, START.ROPE is the name of the hanging rope drawing. Since it is the first rope encountered in the game, I called it START.ROPE. It is best not to give any object a name that has two or more words with blank spaces in between, since this can also lead to confusion in the program.
As I mentioned before, I like to precede all new text with a line of dots to set it apart from older text already in the text window. This includes descriptions of objects given when the object is clicked on. The short code above is an example of this. If the player clicks on either of these immobile objects, a dotted line is printed. Since it finishes with END, the program can continue until it prints the text in the object's data.
PRINT{The shot ricochets off the stone, with no effect.}
EXIT
IF{TEXT$=BEAM}OR{TEXT$=BOARD}OR{TEXT$=TIMBER}THEN
SOUND{GUN}
PRINT{The large beam takes the shot with little damage.}
EXIT
IF{TEXT$=ROPE}THEN
PRINT{Don't shoot the rope!}
EXIT
PRINT{You can't shoot that.}
EXIT
This section handles the word SHOOT. Shooting an object is not the same as using the weapons menu, which is ONLY for combat. If you used the weapons menu to handle shooting at objects, there would be no way to determine which object the player wanted to shoot.
Usually this kind of code would include an IF/THEN statement to determine whether or not the player had a gun. But once again, space was tight, and since shooting these objects gave no real results, I left that condition out of the code.
IF{TEXT$=BREAK}OR{TEXT$=HIT}THEN
PRINT{................................}
IF{TEXT$=ROCK}OR{TEXT$=CEILING}THEN
PRINT{You have no way to break the tunnel stone.}
EXIT
IF{TEXT$=BEAM}OR{TEXT$=BOARD}OR{TEXT$=TIMBER}THEN
PRINT{You can't break such a thick beam.}
EXIT
PRINT{You can't break that.}
EXIT
This part's pretty simple. However, this was another case where I left in a line that could have been left out. Since I put a default response for HIT and BREAK in the global code, I could have just put END at the bottom of this section and left off the "You can't break that" reply. (This has been corrected in later versions of the game.)
IF{TEXT$=TIE}THEN
PRINT{...........................}
IF{TEXT$=ROPE}THEN
IF{TEXT$=BEAM}OR{TEXT$=BOARD}OR{TEXT$=TIMBER}THEN
IF{ROPE=PLAYER@}THEN
MOVE{BEAM ROPE.2}TO{SCENE@}
MOVE{ROPE}TO{STORAGE@}
PRINT{The rope is tied to the beam.}
EXIT
PRINT{You don't have a rope.}
EXIT
IF{TEXT$=ROCK}THEN
PRINT{You can't tie the rope to the rock.}
EXIT
PRINT{You can't tie the rope to that.}
EXIT
PRINT{Tie what?}
EXIT
This code handles attempts by the player to tie the rope to things. The most likely things the player might want to tie the rope to are handled specifically: Tying the rope to the beam, or tying the rope to the rock. Since it isn't likely that the player would want to tie it to the beam he used to get the rope, it is assumed that the player wants to tie it to a support beam. Anything other than the rock or beam gets the default response, "You can't tie the rope to that." Entering just TIE prompts the player for more details.
IF{TEXT$=PUT}AND{TEXT$=ROCK}AND{TEXT$=BEAM}THEN
PRINT{You can't put the rock on the beam.}
EXIT
Some players will try to put the rock on the beam, or the beam on the rock. This handles both situations.
IF{TEXT$=PRY}OR{TEXT$=LEVER}THEN
PRINT{You can't do that here.}
EXIT
This handles actions attempted by some players, which won't work and aren't covered by any other defaults.
PRINT{That would cause the whole shaft to cave in.}
EXIT
This is a response to any attempt to pull the rope after it has been tied to the support beam. If the player tries to pull the hanging rope, he'll just get the global default, "You can't move that".
This ends the scene code for that scene. Obviously, there were some mistakes, mainly duplicated code. That's one of the things you have to watch out for when programming a complex scene. When I programmed this scene, I was still trying to work out standardized ways of handling complex commands. By the time I'd finished the first major puzzle (escaping the mine), I had a little better feel for how I wanted to handle such things, and was able to produce more polished code in the rest of the game. I think I'll call this Part One. In Part Two, I'll go through some of my later codes, and take a look at a more polished handling of complex actions. In the meantime, this is still good, workable code, and should give you a pretty good idea of the uses of nested conditional statements, default responses, END versus EXIT, and other features of advanced WB programming.
